Merge units

Merging units is the process of combining all apps, sites, and users from one unit into another, creating a single shared collaboration boundary with a unified user directory and Teamwork Graph. If you have more than one unit, you may want to consolidate them to manage your Atlassian footprint and keep your apps, users, and groups in one place.

Only organization admins can initiate a merge request by contacting us.

When you merge units, we’ll transfer all your apps, users, and groups from one unit to another. After the transfer, the source unit gets deleted.

動作の仕組み

Merging units is a multi-phase process where apps and sites from the source unit are unlinked and relinked to the destination unit. We also create a temporary source unit during the unlinking and relinking process and delete both the source units later.

• Unified directory: All users from both units are combined into a single user base.

• Expanded collaboration boundary: The collaboration boundary range increases, allowing Rovo and cross-app search to access data across all sites in the new combined unit that users have access to. Existing app access and permissions will be retained.

• Consolidated sites and apps: Merging will unlink all apps and sites associated with the source unit and relink them to the destination unit as-is.

• Administrative shift: Source unit admins become unit admins in the destination unit.

When to merge units

Before you begin, determine whether merging unit is right for you or if you should transfer your app data instead.

You could consider merging units if:

• your organization is over-partitioned and you want to simplify administration by having a single set of unit admins oversee a larger group of sites

• you want to view and manage all users, verified domains, and app instances in a single unit

• you want to configure a single allocation policy that provisions users across all sites in a single user directory

• teams in separate units need to share a single Teamwork Graph for search, Rovo, and @mentions

• if you want to maintain admin autonomy at the unit level while ensuring organization-wide security and policy control

When to keep units separate

You should avoid merging units if:

• your current setup is highly complex, and the impact of resolving pre-flight blockers outweighs the benefits of consolidation

• your compliance or regulatory constraints require you to keep users and data separate within your organization

What to keep in mind before merging units

Before you begin, you need to meet these prerequisites:

• Don't remove your allocation policies before Support has prepared your merge plan.

• User access settings in the source unit must be reset. How to Reset App Access Settings Before a Product Transfer.

• No users should have a conflicting status across both units (for example, Active in one and Inactive in the other).

Atlassian will run pre-flight checks to identify blockers before initiating a merge. The steps to clear these blockers can vary depending on the type of blocker, for example, having a domain claimed in the source unit. For a detailed list of common blockers, see Resolving preflight blockers for an organization consolidation.

Request a unit merge

Before raising a request, identify the source and destination unit IDs, and the domains and integrations that require configuration.

To raise a request:

1. Go to Atlassian Support.

2. Under “What can we help you with?”, select Technical Issues and Bugs.

3. Under “Which product is this for?”, select Cloud Administration.

4. Fill in the required details, including your site URL (for example, yoursite.atlassian.net).

5. Make sure to include the source unit and destination unit details.

What happens during a merge

• A dry run simulation is performed to preview changes. The merge can’t proceed without written approval of this report.

• Once you approve the dry run, we’ll execute the merge during a scheduled window, including merging the user directory and Teamwork Graph.

• During the execution window, some parts of Atlassian Administration will be in read-only mode. You can’t add apps, sites, users, create groups, Rovo agents, or modify subscriptions.

• User access to Jira, Confluence, and other apps remains active throughout the process.

• To avoid conflicts, groups with identical names in both units are renamed using the format {groupName}-{SourceunitName}.

• If a user is active in one unit but inactive in the other, they’ll be inactive in the merged unit. Atlassian support will help identify and resolve these mismatches before the merge.

What to do after the merge

Once the units are merged:

• Confirm that users have the correct app access and roles within the destination unit.

• Review renamed groups to ensure they align with your naming conventions.

• Confirm that Marketplace apps are functioning correctly and subscriptions are aligned within the merged unit.

• Re-verify any domains that were removed from the source unit during the pre-consolidation.

• Reconfigure user provisioning and identity provider allocation policies in the destination unit to reflect the new combined user base.